the URL can be replaced by .github/release.env.
the mainnet and testnet config of the new release is obtained from here

release.env still pointing to v1.1.8 and that is why I have a ARG to build on.

Actually every time a new version is released the additional files come from here, so it will be the same if releas.env doesn't update

The reason I want you to use release.env is that developers will most likely forget to update the Dockerfile when they release a new version

when each release, no need to update the BSC_VERSION in Dockerfile, the build process should pass in --build-arg for the new version to be used, similar to the new target docker in makefile.

BSC_VERSION=v1.1.10 make docker

Additionally, this won't cause confusion for developer between the regular release in the github repo and configuration version being used in Dockerfile.

Most of the flags do not yet support the reading of env...
Must use an additional script to convert to flag, or we need to add support

the reason which I suggest to only support 2 BSC unique env: BSC_NETWORK & BSC_DATA_DIR is that geth has quite a few command line options and is quite familiar by the developers. to keep the compatibility and minimise the maintenance for the script. BSC_NETWORK is used to boot the node to different network. default /data will be convenient to configure docker image, specially when hosting in k8s when mounting volume. config.toml & genesis.json can also be mounted by configmap in k8s into the BSC_HOME/mainnet/ orBSC_HOME/testnet/ before bootstrap script kicks in.

another thought on building network specific image is to use another ARG: <mainnet|testnet> to build image for mainnet & testnet separately, this will end up with two image tags, e.g. ghcr.io/bnb-chain/bsc:v1.1.11-mainnet, ghcr.io/bnb-chain/bsc:v1.1.11-testnet. the config in the docker image will only host the config from the network..this will give much clean image but extra image tag.

1. I agree with you, but I just want to say that the DIFF_SYNC=true environment variable has no effect here
2. I think building it as an image is enough, the program is the same, just the configuration is different

sample docker-compose file just updated to reflect the usage with command line.
in k8s, it will look like

containers:
  - name: client
    image: bnb-chain/bsc:v1.1.11
    args: ["--http.addr", "0.0.0.0", "--http.port", "8545", "--http.vhosts", "*", "--verbosity", "3"]
    env:
      - name: BSC_NETWORK
        value: mainnet